home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000024_icon-group-sender _Mon Aug 29 23:46:57 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 30 Aug 1994 05:15:04 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: 29 Aug 1994 23:46:57 -0400
  4. From: nmw@ios.com (Nick Williams)
  5. Message-Id: <33ua3h$51h@ios.com>
  6. Organization: Internet Online Services
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <Cv9Jvr.AC4@world.std.com>, <33smt8$meg@ios.com>, <1994Aug29.223512.12423@kf8nh.wariat.org>
  9. Subject: Re: Icon - still alive??
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. In article <1994Aug29.223512.12423@kf8nh.wariat.org>,
  13. Brandon S. Allbery <bsa@kf8nh.wariat.org> wrote:
  14. >Binary file I/O for non-character data would be nice.  Or, alternatively,
  15. >functions akin to Perl's pack()/unpack().  I have several Perl scripts I would
  16. >happily move to Icon if I didn't have to manipulate C (short) and (long)
  17. >values in native format (no, I don't get to set the format of the files).
  18.  
  19. I thought reads() was meant to be used for binary data, am I wrong? If
  20. characters in Icon can be treated as plain bytes then pack()/unpack()
  21. type procedures could be built upon reads()/writes().
  22.  
  23. >++Brandon
  24. >-- 
  25. >Brandon S. Allbery KF8NH     [44.70.4.88]          bsa@kf8nh.wariat.org
  26. >Linux development:  iBCS2, JNOS, MH
  27. >Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh
  28.  
  29. Nick
  30.